Mobile IPv6 (MIPv6), which is described in IETF RFC 3775, allows users of mobile communications devices to move from one network to another whilst maintaining a permanent IP address, regardless of which network they are in. This allows the user to maintain connections whilst on the move. For example, if a user were participating in a Voice Over IP (VoIP) session and, during the session the user moved from one network to another, without MIPv6 support the user's IP address may change. This would lead to problems with the VoIP session.
A Mobile Node (MN) is allocated two IP addresses: a permanent home address and a care-of address (CoA). The CoA is associated with an access network that the user is currently visiting. To communicate with the MN, packets are sent to the MN home address. These packets are intercepted by a Home Agent (HA) in the home network, which has knowledge of the current CoA. The Home Agent then tunnels the packets to the CoA of the MN with a new IP header, whilst preserving the original IP header. When the packets are received by the MN, it removes the new IP header and obtains the original IP header. The MN sends packets to another node by tunneling them to the HA, encapsulated in packets addressed to the HA. For each packet, the HA removes the encapsulating packet, restores the original packet and forwards it to the intended destination node.
Proxy Mobile IPv6 (PMIPv6), IETF draft-sgundave-mip6-proxymip6-02, describes a Mobile Access Gateway (MAG) function. This function emulates home link properties in order to make a MN behave as though it is on its home network and allows support for mobility on networks that would not otherwise support MIPv6. A key difference between PMIPv6 and MIPv6 is that using MIPv6, a MN has control of its own mobility signalling, whereas using PMIPv6, a MN does not have control of its mobility signalling. The basic components of a PMIPv6 architecture are illustrated in FIG. 1.
A MAG 101 is usually implemented at the access router. The MAG 101 sends and receives mobility related signalling on behalf of a MN 102. When a MN 102 connects to an access router having a MAG 101, the MN 102 presents its identity in the form of a Network Access Identifier (NAI) as part of an access authentication procedure. Once the MN 102 has been authenticated, the MAG obtains the user's profile from a policy store. The MAG 101, having knowledge of the user profile and the NAI, can now emulate the MN's home network. The MN 102 subsequently obtains its home address from the MAG. The MAG 101 also informs the MN's 102 Local Mobility Anchor (LMA) 103 of the current location of the MN 102 using a Proxy Binding Update message. The Proxy Binding Update message uses the NAI of the MN 102. Upon receipt of the Proxy Binding Update message, the LMA 103 sets up a tunnel to the MAG 101 and sends a Proxy Binding Acknowledgement to the MAG. On receipt of the Proxy Binding Acknowledgement, the MAG 101 sets up a tunnel to the LMA, effectively forming a bidirectional tunnel. All traffic to and from the MN 102 is routed through the LMA 103 via the bidirectional tunnel. A MAG may serve many MNs associated with the same LMA. The MAG and the LMA do not need to have a dedicated bidirectional tunnel for each MN. Instead the same bidirectional tunnel can be used for the traffic of all the MNs that are associated with the same LMA and that are currently being served by the same MAG.
The LMA 103 intercepts any packet that is sent to the MN 102, and forwards the intercepted packet to the MAG 101 through the tunnel. On receipt of the packet, the MAG 101 removes the tunnel header and sends the packet to the MN 102. The MAG 101 acts as a default router on the access link. Any packets sent from the MN are sent via the MAG 101 through the tunnel to the LMA 103, which then sends the packet on to its ultimate destination.
Simultaneous Multi-Access describes a function of a communications network that allows a MN to combine different radio and/or fixed access technologies, as illustrated in FIG. 2. The MN 102 can simultaneously use several interfaces and different access networks (AN1 and AN2), which may employ different access technologies, in a communications session. Different traffic flows, belonging to different applications, can be transferred between different access networks, independently of each other.
MIPv6 can be extended to support Simultaneous Multi-Access (see R. Wakikawa et al., “Multiple Care-of Addresses Registration”, Internet-Draft draft-ietf-monami6-multiplecoa-02, March 2007). Where more than one access is used, a MN has a CoA for each access. A Binding Unique Identifier (BID) is associated with each CoA, and the BID indicates which CoA a Binding Update (BU) relates to. If the BID associated with a new CoA is already in use, the new CoA replaces the one previously associated with the BID, whereas if the BID is not already in use, the new CoA is added to any previously existing CoAs. Since MIPv6 is host-centric (that is to say, the MN is in control of its mobility signalling), with all the mobility signalling flowing between the MN and the HA, the MN has a complete overview and complete control of how CoAs are added to or replacing each other, by assigning the BIDs appropriately.
The mechanisms described in R. Wakikawa et al., “Multiple Care-of Addresses Registration” can also be used to extend PMIPv6 in order to provide PMIPv6 with simultaneous multi-access capabilities. However, using PMIPv6, the MN is not in control of its mobility signalling. As described above, mobility signalling is handled by a MAG on behalf of the MN. A Proxy Binding Update (PBU) is triggered when the MN attaches to an access and the MAG responsible for the access. This means that a MN has no way of indicating its intentions regarding how the accesses are to be used in terms of PMIPv6, i.e. whether a new access should be added to the already used accesses or replace one or more old one(s).
Furthermore, even if a MAG did know whether a new CoA should be added to the existing CoAs or replace an old one, it would not know which BIDs other MAGs in the network have assigned to the existing CoAs, so it could not ensure the new CoA replaces another CoA (by assigning the same BID to the new CoA), nor could it ensure that the new CoA is added to the existing CoAs (by assigning a unique BID to the new CoA). This lack of coordination of BID assignment is a problem.
In a simultaneous multi-access scenario it is not only desirable to be able to control how accesses (and thus CoAs and BIDs) are managed in terms of additions and/or replacements of CoAs, but also to be able to control which data flows are sent over which accesses. One way to control data flow management is by using filter rules.
Filter rule management is designed to handle flow management in simultaneous multi-access scenarios as described in Internet-Draft “A Filter Rule Mechanism for Multi-access Mobile IPv6” (draft-larsson-monami6-filter-rules-02). A filter rule comprises a match expression and a virtual interface identifier, termed a Filter Interface Identifier (FIID). A filter rule indicates through which interface or to which CoA a data packet matching the match expression should be routed.
To associate a filter rule with a specific interface or CoA, the filter rule's FIID is bound to an interface (for packets to be sent from the node the filter rule relates to) or a mobility protocol specific identifier, for example a BID (for packets to be sent to the node the filter rule pertains to). The latter type of FIID binding (binding the FIID to a mobility protocol specific identifier such as a BID) must be signalled to nodes that are to send packets to the node that the filter rule relates to (e.g. a Home Agent or a correspondent node using the MIPv6 route optimization mode or a PMIPv6 LMA). Although filter rule management has been designed to be independent of the mobility protocol, it is particularly suitable for MIPv6. The signalling of FIID-BID bindings is integrated in the signalling described in Internet-Draft “Filter Interface Identifier Binding in Mobile IPv6” (draft-kauppinen-monami6-binding-filter-rule-00) [5]. Specifically FIID-BID bindings are signalled in Binding Updates.
Filter rules (and FIID-interface bindings) are typically created (or otherwise installed) in the MN, which is normally the entity that has an overview of the available accesses, the relevant applications and the user's preferences. The filter rules for outgoing packets (from the MN) need only be stored locally in the MN, whereas the MN sends the filter rules for incoming packets (destined for the MN) to nodes that need them, e.g. its MIPv6/monami6 HA and CNs (using route optimization), and signals the appropriate FIID bindings (e.g. FIID-BID bindings) to these nodes.
However, the mechanisms described in Internet-Draft “Filter Interface Identifier Binding in Mobile IPv6” (draft-kauppinen-monami6-binding-filter-rule-00) are not the only possible ways to bind a filter rule to a BID and to signal such a binding to a remote node. Similarly, using an FIID is not the only way to identify a filter rule. Alternative, albeit similar, mechanisms are described in the Internet-Draft “Flow Bindings in Mobile IPv6 and Nemo Basic Support” (draft-soliman-monami6-flow-binding-04). In this Internet-Draft a Flow Identifier (FID) in combination with the MN's home address are used to identify a flow and its binding. A flow is defined using the same kind of parameters as a match expression of a filter rule (which is used to match the flow to which the filter rule applies) and hence a flow description and a filter rule match expression essentially define the same thing. Internet-Draft draft-soliman-monami6-flow-binding-04 also uses Binding Updates to signal filter rule/flow-to-BID bindings to a remote node, e.g. a Home Agent or a CN, although FIDs are used instead of FIIDs.
There are therefore different means to identify a filter rule/flow (e.g. an FIID, an FID or a combination of a home address and an FID). For the purpose of the present invention the specific details of the identification means are not essential. The general term ‘filter rule identifier’ is used herein to refer to any type of filter rule/flow identifier, examples of which include a FIID, a FID or a combination of a home address and a FID. Similarly, the term ‘filter rule-BID binding’ is used herein to refer to a binding between a filter rule and a BID in general, whether it is using an FIID, an FID, a combination of a home address and an FID or any other means to identify the filter rule being bound to a BID. Consequently, the term ‘filter rule-interface binding’ is used herein to refer to a binding between a filter rule and an interface in general, whether it is using an FIID, an FID, a combination of a home address and an FID or any other means to identify the filter rule being bound to an interface.
Typically the filter rules for outgoing and incoming packets are symmetric, such that outgoing and incoming packets of the same flow are transferred via the same access interface, but asymmetric filter rules are also possible.
Filter rules can potentially be a very useful flow management tool in a simultaneous multi-access environment, but managing filter rules in conjunction with PMIPv6 is problematic.
One problem stems from the fact that the MN should not be aware of its LMA and should not have a direct relation to it (ideally the MN should not even have to be aware of that it is being served by PMIPv6). The MN can therefore not transfer filter rules directly to the LMA.
Another problem of filter rule management in conjunction with PMIPv6 is that when monami6 signalling is used for PMIPv6, it becomes problematic to integrate the filter rule-BID binding signalling. The reason is that the PMIPv6/monami6 messages, and in particular Proxy Binding Updates (PBUs), are sent from the MAGs instead of from the MN. A MAG does not have an overview of all of the accesses in use by the MN. Furthermore, a MAG is not aware of the filter rules that the MN has created (or otherwise installed) and their filter rule-interface bindings. A MAG therefore cannot signal filter rule-BID bindings to the LMA on behalf of the MN.
A scenario that further complicates filter rule management is when a MN is attached to multiple different access links connected to the same MAG, as illustrated in FIG. 3. In this case filter rules must be installed not only in the MN and the LMA, but also in the MAG 2 (in the example of FIG. 3) in order for the MAG 2 to know over which of its access links it should send a downlink packet. All MAGs advertise the same (home) prefix to a MN, and so the MN will not be able to distinguish the scenario illustrated in FIG. 3 from scenarios where the different access links belong to different MAGs. A way to allow the MN to distinguish this scenario is to provide each MAG with a different link-local address and configure the same link-local address on all access link interfaces of the same MAG. However, such a scheme might interfere with one of the suggestions in S. Gundavelli et al., “Proxy Mobile IPv6”, Internet-Draft draft-sgundave-mip6-proxymip6-02, March 2007, which is to configure the same link-local address for all MAGs in the same PMIPv6 domain.
One of the problems in handling simultaneous multi-access scenarios in a proxy mobile communications network is a lack of control of how CoAs for the MN (and thus accesses) are handled in the LMA. That is, a MN has no way of indicating how the accesses should to be used in terms of PMIPv6, for example whether a new access should be added to the already used accesses, or replace one or more old accesses. Neither the MAGs nor the LMA have any way of anticipating the MNs intentions. Furthermore, there is a lack of coordinated BID assignment. Even if a MAG did know whether a new CoA should be added to the existing CoAs or replace an old one, it would not know which BIDs other MAGs in the network have assigned to the existing CoAs. An additional problem is that the MN cannot send filter rules directly to the LMA, because it has no direct relation with the LMA, does not know the LMA's IP address and ideally the MN is not even aware that it is being served by an LMA. Furthermore, using filter rule-BID binding signalling integrated in PMIPv6/monami6 messages is problematic, because the MAGs, which handle the PMIPv6/monami6 signalling on behalf of the MN, do not have the necessary overview of the accesses that the MN is using. The MAGs are also not aware of the filter rules that the MN has created (or otherwise installed) and their filter rule-interface bindings. Hence a MAG cannot signal filter rule-BID bindings to the LMA on behalf of the MN. WO 2007/039016 describes a method of allowing simultaneous use of a home network and a foreign network by a multihomed MN, but does not allow for control of handling CoAs for the MN.
A general property of the above mechanisms is that they are terminal centric in the sense that the control of flow management is placed in the MN. This is a problem in certain scenarios where operator control is given high priority, for example in some cellular networks.
There is a need for a solution that overcomes the above-described problems of lack of control and coordination of CoAs and BID assignment as well as filter rule management. In addition, it would be desirable to provide a solution that allows more operator control of these mechanisms.